W niniejszym artykule będzie nieco więcej o ludziach, a nie o sprzęcie. Konkretnie to o ludziach ze złym nastawieniem do swojego hobby lub też do życia. Być może rozpiszę się w przyszłości konkretnie na temat niuansów technicznych związanych z tym fascynującym urządzeniem, jakim jest RAM Expansion Unit, ale nie dzisiaj.

REU to rozszerzenie pamięci zaprojektowane pierwotnie dla komputera Commodore C128 przez firmę CES w 1985 roku. Jest całkowicie kompatybilne z C64 i to dzięki tej kompatybilności powstała na nie większość oprogramowania. Urządzenie składa się z pamięci DRAM o wielkości 128 KB, 256 KB oraz 512 KB (w zależności od modelu) oraz układu DMA, jako jej kontrolera. Ten właśnie chip MOS 8726 (nazywany REC) czyni REU wyjątkowym i jest odpowiedzialny za wszystkie jego zalety i wady.

W kontekście rozszerzania pamięci w komputerach 8-bit mamy dwa podejścia. Pierwsze to metoda stronicowania pamięci. Polega na podstawieniu bloku pamięci rozszerzanej zamiast oryginalnej w łatwo zarządzanych (małych) blokach. Tak działają kartridże, które są de facto rozszerzeniami pamięci ROM, czego przykładem jest GeoRAM firmy Berkeley Softworks (tak, tej samej, która napisała system GEOS). Popularne w Polsce rozszerzenie +60K również działa na tej zasadzie, choć jego strona pamięci jest duża. Rozwiązanie takie ma dwie kluczowe zalety, z których jedna jest po dziś dzień istotna. Mianowicie w ramach podłączonej aktualnie strony pamięci (banku/bloku) możliwe jest uruchamianie w nim kodu tak, jakby był częścią pamięci RAM komputera. Druga, nieistotna już dziś zaleta, to koszt takiego rozwiązania. Generalnie każdy ćwok z lutownicą i podstawową wiedzą na temat adresowania pamięci w swoim retro komputerze jest w stanie sobie takie rozszerzenie zbudować za grosze. Wadą takiego podejścia jest oczywiście fakt, że mapowane strony zasłaniają pamięć oryginalną, oraz że trzeba je przełączać programowo. Wad tych pozbawione jest REU, które jest maszyną kopiującą dane z pamięci C64 do pamięci REU i odwrotnie bez pomocy procesora z zawrotną prędkością. Zbyt piękne, aby mogło być prawdziwe? Trochę tak... Nie dość, że REU z zasady nie umożliwia uruchamiania kodu w swojej pamięci, gdyż ta nie jest widziana przez CPU (istnieje jednak możliwość zasymulowania takiego zachowania), to jeszcze zatrzymuje jego pracę podczas wykonywania transferu. Dzieje się tak, ponieważ REC pracuje w tej samej połówce cyklu zegarowego w której dostęp do RAM komputera ma procesor. Nie tego spodziewaliście się po elektryzującym skrócie „DMA”, prawda? Zresztą REU pełne jest powodujących błysk w oku możliwości, które w praktyce okazują się właściwie bezużyteczne. Ja jednak nie będę ich tutaj wszystkich poruszał, gdyż nie to jest celem artykułu.

Tak więc skoro jest tak źle, to dlaczego rozszerzenie to odniosło taki sukces na tle swoich prostszych braci, a dema nań napisane spowodowały opad szczęk naszym znajomym na demoscenie z innych platform sprzętowych? Jest to gra liczb. Za pomocą procesora naszego C64 możemy przenieść dane z jednego miejsca w drugie w pamięci RAM z prędkością dochodzącą do kilkudziesięciu KB/s. W przypadku rozszerzenia pamięci, takiego jak GeoRAM, którego strony mają po 256 bajtów, z tą prędkością jest znacznie gorzej. Układ DMA w REU jest taktowany zegarem C64 i choć zatrzymuje CPU na czas transferu, to jednak przesyła 1 bajt danych w ciągu jednego cyklu zegarowego, co daje prędkości dochodzące do 1 MB/s. REU przy GeoRAM jest jak Tesla przy skuterze. Co więcej, obsługa jest banalnie prosta. Wystarczy w jednym rejestrze podać skąd chcemy kopiować, w drugim rejestrze ile tego ma być, w trzecim, gdzie ma to wylądować i w czwartym podać kierunek kopiowania i uruchomić transfer. Voila! Żadnych skomplikowanych procedur kopiujących, żadnego przełączania stron. Jeśli nie robi to na Tobie wrażenia, to wyobraź sobie, że pożądany bajt danych dostajesz w pożądanym miejscu dwukrotnie szybciej niż trwa czas wykonania najszybszego rozkazu procesora 6510. Skopiowanie bloku danych z jednego miejsca w RAM C64 do RAM REU i z powrotem do RAM C64 w inne miejsce będzie w dalszym ciągu pięć razy szybsze niż gdyby to zrobić za pomocą CPU. Właściwie to urządzenie działa tak szybko, że wprawiony koder jest w stanie za pomocą REU generować grafikę HIRES na zdjętej dolnej i górnej ramce bez użycia sprajtów! No dobrze... Tylko spokojnie... Wspomniałem wyżej o ustawieniu czterech rejestrów do wykonania transferu. Ten ostatni rejestr (poleceń) pominiemy w naszych rozważaniach. Przyjrzyjmy się trzem pierwszym. Dwa z nich to rejestr długości transferu oraz rejestr bazowy pamięci C64. Oba są dwubajtowe, ponieważ mamy w komputerze 64 KB pamięci i transfer bloków większych niż ta pamięć w adres, który nie istnieje, jest bez sensu. Trzeci natomiast jest bardzo interesujący. Jest to rejestr bazowy REU i składa się z trzech bajtów, ponieważ pamięć REU znacznie przekracza 64 KB. Wspomniałem też wyżej, że metoda stronicowania pamięci jest powolna nie tylko dlatego, że kopiowanie odbywa się za pomocą CPU, ale też dlatego, że kopiowanie trzeba przerywać, aby przełączyć stronę na następną. Rejestr bazowy C64 i bazowy REU zwiększają się wraz z transferem DMA automatycznie, więc żadna ingerencja programisty nie jest konieczna. Co jednak się stanie, jeśli zażyczymy sobie transferu w wypadku, gdy wartość w rejestrze długości transferu będzie większa od wartości w rejestrze bazowym C64 lub REU? Innymi słowy, co się stanie, jeśli zechcemy skopiować na przykład 256 bajtów pamięci REU na 128 bajtów przed jej końcem? Czy transfer zostanie zatrzymany z błędem po 128 bajtach? Właściwie to nie. Pamięć zostanie zawinięta, to znaczy 128 bajtów zostanie skopiowane z końca pamięci REU, rejestr się wyzeruje i drugie 128 bajtów zostanie wysłane z początku pamięci REU. Brzmi sensownie, prawda? Tak więc w przypadku największego REU 1750 produkowanego przez Commodore o pojemności 512 KB, rejestr bazowy REU składa się z trzech bajtów, ale nie wszystkie bity są wykorzystane. Jak łatwo policzyć, do zaadresowania takiej pamięci potrzeba jedynie 19 bitów w tym rejestrze (2^19 = 524 288). Co więc z pozostałymi 5 bitami? NIESTETY DO DZISIAJ NIC! To przez te 5 bitów rozpętała się niemal wojna religijna i właściwie tytuł tego artykułu powinien brzmieć „Pięć bitów”. Jednakże zanim do tego dojdę, warto przytoczyć jeszcze trochę historii. Otóż MOS 8726 w zamyśle został zaprojektowany jako kontroler DMA dla pamięci 512 KB. Pozostałe 5 bitów w rejestrze pozostaje ustawione, natomiast w wersjach 1700/1764 przestrzeń adresowa jest nadal 19-bitowa, a pojemność ograniczona jest zworą na płycie głównej oraz użytą pamięcią. Jednakże już na początku lat dziewięćdziesiątych użytkownicy zaczęli fantazjować o większej ilości pamięci w swoich REU, co doprowadziło do bardzo paskudnej praktyki z inżynierskiego punktu widzenia zaproponowanej prawdopodobnie przez Andrzeja Mileskiego. Ponieważ w tych latach nie dało się metodą chałupniczą przeprowadzić inżynierii wstecznej kontrolera REC i zreplikować jego funkcjonalności w inny sposób, posłużono się bardzo brudnym hackiem. Polegał on w uproszczeniu na nalutowaniu dodatkowych 512 KB RAM na istniejące w REU i dodaniu układu TTL, który podłączony do kolejnego bitu rejestru bazowego REU umożliwiał stronicowanie tej pamięci. Tak zaczęła powstawać piramida REU. Pobór energii znacząco wzrastał, choć już samo Commodore dodawało do REU dla C64 nowy zasilacz 2.5A. W szczytowym momencie projekty DIY przewidywały rozszerzenie REU tą naleśnikową metodą nawet do 4 MB! Posiadacze się cieszyli z megabajtów, a REC jak miał przestrzeń adresową 19 bit, tak miał nadal... Nadeszła więc końcówka lat dziewięćdziesiątych i za klonowanie REU wzięła się firma Creative Micro Designs, skupiająca dawnych inżynierów Commodore. Można by pomyśleć, że oto teraz projekt REU zostanie poprawiony, a praktyki domorosłych elektroników przejdą do historii. Niestety, nowy produkt CMD zaprezentowany w 1997 roku o nazwie 1750XL był tylko liftingiem starego REU. Używał tego samego kontrolera MOS 8726 do którego zapasów magazynowych CMD miało dostęp i powielał nieeleganckie rozwiązanie z 1990 roku. Urządzenie dzięki nowym, mniejszym i bardziej energooszczędnym pamięciom oraz zastosowaniu nowszych układów GAL, zamiast TTL, dało się zamknąć w obudowie zwykłego kartridża, a ten działał ze standardowym zasilaczem C64. Firma właściwie wprowadziła bardzo niewiele innowacji w stosunku do małego Super 1750 Clone z 1991 roku od firmy Chip Level Designs, który spełniał te same kryteria. Użytkownicy znów się cieszyli nowym, ładnym 2 MB REU za $99 za sztukę i nie zważali uwagi na to, że nadal jest to tylko REU 512 KB z czterema stronami pamięci. Mija kolejnych 10 lat i w sieci pojawiają się wykonywane w małych partiach klony REU o pojemności 1 MB za $65 za sztukę napędzane... Tak, zgadliście, nieśmiertelnym REC chipem z najwyraźniej nigdy nie kończących się zapasów! Prawdopodobnie jedyne rozszerzenie pamięci w historii oparte o chip DMA, którego wartość da się przeliczyć na strony pamięci...

Jednakże wiatr zmian powiewał już od dobrych kilku lat zwiastując postęp w elektronice, który miał zajrzeć pod strzechy domu przeciętnego amatora elektroniki dostarczając mu możliwości, jakie wcześniej leżały jedynie w rękach dużych firm. Mowa oczywiście o układach programowalnych. Te znane były już w latach osiemdziesiątych XX wieku, jednak były wówczas zbyt proste i zbyt drogie, by tchnąć nowe życie w retro komputery na większą skalę. Rozwój układów CPLD i FPGA oraz darmowych lub prawie darmowych narzędzi do ich programowania umożliwił całemu nowemu pokoleniu „Mileskich” na tworzenie replik układów lub całych retro komputerów. Tak więc odtworzenie funkcjonalności MOS 8726 przestało być problemem i znalazł się taki „Mileski”, który to zrobił. Właściwie to jest aż tak Mileski, że nazywa się Gideon Zweijtzer i jest Holendrem. Ów inżynier zaprezentował w 2008 roku swój wielozadaniowy kartridż (koncepcja już wtedy znana) dla C64/C128, który zapewniał w swojej programowalnej strukturze funkcjonalność całego REU o pojemności aż 16 MB! Należy wspomnieć, że dekada milenijna przyniosła nam nie tylko tanie układy FPGA, ale również komputery 32 bit na tyle szybkie, aby emulować C64 z pełną prędkością i to z przyłączonymi najwymyślniejszymi wirtualnymi akcesoriami dla tego komputera. Przykładowo emulator Vice oferował już od dłuższego czasu REU o maksymalnej pojemności 16 MB i uwaga... jego wirtualny REC miał pełną 24-bitową przestrzeń adresową przy wyborze takiej właśnie pojemności! Więc znamy zasadę działania, mamy ją przetestowaną na emulatorach, mamy technologię, by tworzyć własne chipy. Pomyślelibyście, że wreszcie po ponad 20 latach od zaprezentowania REU drzwi do ulepszenia jego specyfikacji i wyeliminowania błędów stoją otworem!

Nie... Niestety nie i na własnej skórze miałem się przekonać, jak bardzo NIE. Otóż w 2010 roku grupa Crest zwróciła uwagę kilku programistów na REU wydając swoją prezentację o nazwie BluREU. Ludzie z tej legendarnej formacji uzbrojeni w dokonania minionej dekady, takie jak tryb graficzny NUFLI oraz implementacje programowe REU 16 MB w Vice i w kartridżu 1541 Ultimate pana Gideona, napisali program, który strumieniował wideo z pamięci REU z częstotliwością kilkunastu klatek na sekundę i to w trybie NUFLI. To robiło wrażenie. Mnie jednak, jako stuprocentowego ignoranta odnośnie tego trybu graficznego nie interesowało strumieniowanie wideo. Kiedyś wyczytałem, że odtwarzanie sampli za pomocą REU jest niemożliwe ze względu na szybkości transferów i choć pojawiło się kilka dem obalających ten mit, ja postanowiłem sprawdzić jak sobie poradzę. Tak, jak członkowie grupy Crest, miałem w porównaniu do swoich poprzedników nie dość, że dostęp do bardzo pojemnego REU, do którego pliki mogłem wczytywać bardzo szybko, to jeszcze byłem uzbrojony w znaną od 5 lat procedurę odtwarzania sampli 8 bit SounDemoNa. Po długich próbach optymalizacji, pod koniec 2010 program Limon REU Wave Player był gotowy i potrafił odtworzyć plik wave z jakością 44100 Hz 8 bit. To na wielu zrobiło wrażenie. Jednakże powstał pewien problem. Mój program doskonale działał na współczesnym emulatorze Vice 2.2, ale nie działał na moim 1541 Ultimate. Po inspekcji okazało się, że Gideon do swojej specyfikacji REU przeniósł wszystkie błędy charakterystyczne dla oryginalnego rozszerzenia Commodore i jego klonów. Zgłosiłem więc na stronę projektu wszystkie, jakie udało mi się znaleźć i czekałem... Tymczasem na forum owej strony (1541ultimate.net) pojawił się wątek dotyczący strumieniowania plików nagranych na kasetach magnetofonowych do pamięci REU. 1541 Ultimate oferował funkcjonalność kopiowania plików programów z kaset magnetofonowych w formie plików audio w celu ich zapisu. Jednakże program, który to robił, funkcjonował podobnie do mojego i działał poprawnie na Ultimate tak daleko, jak daleko sięgała przestrzeń adresowa REC, czyli 19 bitów. Pomyślałem, że to dobry znak, aby proces przyśpieszyć i włączyłem się do dyskusji. Byłem w błędzie... Rozpętałem niemal wojnę.

Tak więc mieliśmy technologię, odpowiednich inżynierów, wiedzę. Mieliśmy wszystko, by naprawić REU. Co stanęło na przeszkodzie? Ludzie... Konserwatyści... Prawdziwi fanatycy... Wtedy nie wiedziałem nawet, że na demoscenie C64 tacy istnieją. To był koszmar! Oczywiście nie wymienię ich ksyw, aby nie robić im obciachu, chociaż jestem pewien, że są dumni ze swoich przekonań. Gideon był chętny do współpracy i w ciągu dnia z nieukrywaną ulgą napisał lepszą specyfikację dla REU, gdyż zaimplementowanie wszystkich błędów istniejących w tym rozszerzeniu zajęło mu wcześniej sporo czasu. Nowe REU w Ultimate działało tak, jak to w emulatorze Vice. Szerokość rejestru bazowego REU zależała od wybranej pojemności REU, a jako gratis Gideon nawet dodał kilka dodatkowych rejestrów, których w oryginalnym REU nie było i usunął pozostałe błędy. Brzmi nieźle, prawda? Nie dla konserwatystów. Ci zdecydowali, że program TAP Writer, o który debata na forum się rozpoczęła, zostanie przepisany tak, aby działał na REU 1750 z brudnym hackiem w postaci stronicowania pamięci. Tylko, że niestety nie będzie, ponieważ funkcjonalność zgrywania kaset jest częścią 1541 Ultimate... Natomiast mój odtwarzacz w odróżnieniu od TAP Writera nie mógł być przystosowany bez utraty jakości odtwarzania do rozszerzenia pamięci stronicowanej, gdyż zarówno polegał na, jak i wymagał pełnych możliwości DMA. Pomyślałem więc, że to problem wiedzy. Jeśli tylko wyjaśnię o co chodzi, nie będzie problemu. Niestety nie pomogło tłumaczenie, że problem kompatybilności nie istnieje, ponieważ z menu Ultimate i tak użytkownik wybiera z jakiego REU chce korzystać. Wszak REU w Vice cieszy się pełnymi możliwościami DMA i nie ma problemu. Zacząłem się więc zastanawiać, co tym ludziom w głowach siedzi i okazało się, że ich punkt widzenia jest następujący. REU zaimplementowane w logice programowalnej to nie jest „prawdziwe REU”. Prawdziwe REU to takie, które używa oryginalnego MOS 8726. To, które zostało rozszerzone według pomysłu gwałcącego założenia REU, to też jest prawdziwe REU. Wszystkie przyszłe specyfikacje REU, niezależnie od swojej pojemności, mają mieć cechy „prawdziwego REU” i ch*j! Dlaczego? Jedyny argument konserwatystów jest taki: Ponieważ REU działające w pełnym trybie DMA mogłoby zachęcić programistów do pisania pod niego programów (!!!). Czyli moi rozmówcy zdawali sobie sprawę z tego, co jest lepsze i że nie ma problemu z kompatybilnością. Chodziło o zatrzymanie postępu tak, by nowe oprogramowanie na REU bez stronicowania pamięci nigdy nie powstało. Przykro mi to mówić moim sentymentalnym znajomym, ale już nigdy raczej nie powstanie. Modowane REU 1750 oraz 1750XL od CMD kurzą się w kolekcjach zbieraczy retro sprzętu. Ludzie, którzy faktycznie używają REU, a mają do wyboru to „prawdziwe” i to „nieprawdziwe”, używają tego nieprawdziwego w Ultimate i Turbo Chameleon 64, których do dzisiaj sprzedano już łącznie z 4-5 tysięcy. Blado wygląda utrzymywanie atawizmów sprzętowych w nowoczesnych implementacjach tylko ze względu na kilkaset infantylnie zmodowanych sztuk, których prawie nikt nie używa, a z którymi kompatybilność i tak da się utrzymać. Ponadto, jeśli perspektywa tworzenia oprogramowania dla oryginalnego REU wydaje Wam się dziś jakkolwiek kusząca, zwróćcie uwagę na wyzwania! Jeśli nie mówimy o syntezie danych do jego pamięci, mówimy o ich ładowaniu... Załadowanie 512 KB REU trzema stronami dyskietki zajmie nam przy wykorzystaniu modułu Action Replay i bardzo szybkiej ręki około 1.5 minuty. Oczywiście wiem, że Action Replay nie może działać w jednym porcie wraz z REU, ale dla dobra argumentu załóżmy, że może. Pewnie nie wydaje się to wiecznością, ale co z tym 1750XL na sterydach? To już 6 minut i 12 stron, czyli 6 dyskietek... No a ile czasu ładować się będzie te 2 MB do tego „nieprawdziwego” REU w Ultimate z karty SD? Około 2 sekundy...

Powiadają, że racjonalnymi argumentami z irracjonalnych poglądów ludzi wyciągnąć się nie da. Tak więc poległem w tej walce. Gideon wycofał się z poprawionej implementacji REU oraz zablokował wątek, gdyż przewojowaliśmy w nim całe święta i sylwester. Jest to zresztą jedyny zablokowany do dzisiaj na tym forum wątek. Nowy 2011 rok rozpoczął się starym konserwatywnym status quo. Po drodze jeszcze napisałem dosyć dokładny program do testowania REU i znalazłem błąd w implementacji Vice, ale zdołowany przejściami odpuściłem i nigdy go nie wydałem. Konserwatyści natomiast nie odpuścili. Jeden z moich adwersarzy dokonał modyfikacji plików źródłowych w emulatorze Vice pozbawiając go od wersji 2.3 pełnego wsparcia DMA dla całej wybranej pamięci REU powyżej 512 KB i tłumacząc to w źródłach kompatybilnością z CMD 1750XL... Mój program przestał działać i to ja zostałem zmuszony do zmniejszenia jakości dźwięku w kolejnej wersji, aby obsłużyć stronicowanie w rozszerzeniu pamięci, które w zamyśle miało być urządzeniem opartym o DMA.

Tak oto zakończył się mój rozdział walki o porządnie zaprojektowane REU. Cechą znamienną konserwatyzmu jest to, że ludzie go wyznający zrobią wszystko, aby podtrzymać swój neoromantyzm, nawet za cenę postępu ku czemuś lepszemu. Tak naprawdę nie ma znaczenia czy jesteś konserwatystą, czy postępowcem, lecz jeśli podtrzymując swój światopogląd (nawet gdy konsensus jest w zasięgu) wmuszasz go innym, jesteś szkodnikiem.

Kilka osób spiera się na CSDb o limit wielkości załącznika, jaki można przesłać na serwer jako produkcję, a który wynosi obecnie 1024 KB. Użytkownik zarzuca, że to mało, administrator argumentuje, że nie chce powielających się kolekcji gier, debata trwa, aż loguje się konserwatysta-szkodnik i z rozbrajającą pewnością siebie wypala, że wielkość załącznika powinna wynosić 170 KB max... no i już wszyscy z 1 MB zadowoleni! Taka commodorowska wersja kompromisu aborcyjnego w Polsce. Wystarczy wyjechać z czymś kompletnie irracjonalnym, jak 170 KB przy istniejących obrazach dyskietek stacji 1571/1581/FD2000/FD4000 i kartridży, a złoty środek przestaje być nawet środkiem. Tego typu argument usłyszałem też w kontekście REU, który pomógł przesunąć środek ze środka na manowce absurdu. Konserwatysta skwitował, iż według niego REU w ogóle jest źle zaprojektowane i powinno być stronicowane od początku do końca... przy 16 MB... W owym czasie myślałem, że takie myślenie wynika z ignorancji, a nie opinii nacechowanej emocjonalnie.

W podobnym klimacie... Po Internecie krąży groteskowy mem ze zdjęciem C64 i podpisem: „W użyciu od 1982 i brak konieczności aktualizacji systemu do dziś”. Yyyy... Co proszę? Niezliczona ilość DOS-ów, interpreterów BASIC, nakładek na system, całych nowych systemów okienkowych i nieokienkowych to powstało dla zabawy, czy dlatego, że tego gówna po 3 latach od premiery nie dało się normalnie używać? W tym kontekście konserwatyzm jest nośnikiem słodkich kłamstw, jakie powtarzamy sobie i innym.

Ja jednak marzę o tym, że być może za kolejną dekadę nadejdzie jakiś inżynier, który będzie potrafił zainspirować ludzi tak, jak ja nie potrafiłem, spojrzy na REU i po prostu je poprawi odwołując się do emocji przyszłych użytkowników, a nie ich rozumu. Dziś wiemy, że wszystkie błędy w tej specyfikacji da się zlikwidować, obsługa DMA może być pełna, funkcja wywoływania przerwań IRQ przez REU może mieć sens, transfery wcale nie muszą blokować pracy procesora, urządzenie może mieć dodatkowe możliwości, a wszystko to wstecznie kompatybilne z istniejącym oprogramowaniem. Wbrew pozorom jest to prostsze do zrealizowania, niż przekonanie do tego zakonserwowanych umysłów.

/Data